feat: include property definitions per label in get_graph_schema (#179)#181
feat: include property definitions per label in get_graph_schema (#179)#181dLo999 wants to merge 3 commits intoDeusData:mainfrom
Conversation
…sData#179) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Add SQLITE_OK guard before bind/step calls, matching existing patterns in store.c. Add LIMIT 50 rationale in comments. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
dLo999
left a comment
dLo999
left a comment
There was a problem hiding this comment.
Review Summary
Adds property definitions per node label and edge type to get_graph_schema. Base columns listed first, then JSON property keys discovered via json_each() with LIMIT 50 cap. Backward compatible — existing label/count fields unchanged.
Findings
- [warning] src/store/store.c:2521,2587 —
sqlite3_prepare_v2()return was unchecked before bind/step calls, deviating from existing patterns. Fixed in follow-up commit: addedSQLITE_OKguard matching the pattern at line 2449. If prepare fails, base columns are still returned (graceful degradation). - [nit] src/store/store.c — LIMIT 50 rationale now documented in inline comments (added in fix commit).
- [observation] No new test for property discovery — existing
store_schema_infotest passes but doesn't validate the newpropertiesarrays. Not blocking since the feature is backward compatible and manually verified.
CI Status
No CI on fork branch. Local: 2741 tests pass, 0 regressions. Behavioral verification against 23K-node project confirms correct output across 14 labels including empty-properties edge cases.
Verdict
APPROVE — Review warning addressed in follow-up commit. Implementation is correct, performant (59ms for 23K nodes), and backward compatible.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Merged — thank you! 🎉Integrated via commit 60dd4df. Great feature — this makes We refactored the property discovery into a shared You've been credited as co-author: Thanks for the thorough behavioral verification across all 14 labels, @dLo999! |
Adds per-label/type property key discovery via json_each() so users can see which properties are available for Cypher queries without trial and error. Base columns listed first, JSON keys appended (capped at 50). Closes #179. Based on #181 by dLo999. Co-Authored-By: Dustin Obrecht <dustin@kurtnoble.com>
2 participants
Closes #179
Summary
Adds property definitions per node label and edge type to
get_graph_schemaoutput. Users can now discover which properties are available for Cypher queries without trial and error.Changes
src/store/store.h: Extendedcbm_label_count_tandcbm_type_count_twithproperties/property_countfieldssrc/store/store.c: Added per-label/type property key queries usingjson_each()incbm_store_get_schema(), with proper cleanup incbm_store_schema_free()src/mcp/mcp.c: Emits"properties"array in JSON output for both node labels and edge typesOutput format (before → after)
Before:
{"label": "Function", "count": 13531}After:
{"label": "Function", "count": 13531, "properties": ["name", "qualified_name", "file_path", "start_line", "end_line", "complexity", "docstring", "is_entry_point", "is_exported", "is_test", "lines", "param_names", "param_types", "return_type", "signature"]}How it works
name,qualified_name,file_path,start_line,end_line) are always listed first — these exist on every nodeSELECT DISTINCT je.key FROM nodes, json_each(nodes.properties) AS je WHERE label = ?(limited to 50 keys)source_id,target_id) plus JSON property keyslabel,count,type) are unchanged — fully backward compatibleTest results
Build: Compiles cleanly on macOS (Apple Clang, arm64)
Test suite: 2741 passed, 0 failed (confirmed flake in
test_pipeline.c:2672did not reproduce on rerun; passes on main intermittently too)Behavioral verification (ran
cli get_graph_schemaagainst real indexed project — codebase-memory-mcp itself, 23,736 nodes, 14 labels):{}){})Edge case: empty properties — Labels where every node has
properties = '{}'(Folder, Project) correctly return only the 5 base columns with 0 JSON properties. Same for edge types with no JSON properties (DEFINES, CALLS).Performance: 59ms total for 23K nodes across 14 labels — negligible overhead from the
json_each()queries.Generated with agent-team via /issue